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Background of the Invention 

Field of the Invention 

This invention relates to an integrated medical database system. More 
specifically, this invention relates to a billing modifier module for a medical database in 
the emergency medical transportation industry. 

Description of the Related Technology 

Current documentation procedures in the medical transport industry are based on 

an inefficient paper and pencil technology. Important information is frequently 
collected on loose sheets of paper. In the environment of emergency medical transport, 
little time is available to neatly chart and document all pertinent and required 



information on a single document. Dispatch data, demographic data and chnical data 
are normally tracked as fragmented pieces of information that are later coalesced into a 
complete patient chart. In many cases, these data include the same information, thus 
forcing the input of redundant information. The resultant chart is therefore vulnerable 
to being incomplete and unreliable. In a medical setting, incomplete information can 
lead to disastrous clinical results. 

This same technology is used to support industry quality improvement and 
billing procedures and submit letters of transport justification. This paperwork is 
usually carried out well after the date the patient is encountered, prolonging account 
receivable times in many instances to the point of compromising and jeopardizing 
service compensation. Inventory stocking and tracking is similarly a victim of extended 
tumover times and is often incomplete and inaccurate. 

The fi-agmentation throughout the medical transport environment is also evident 
in the myriad of entities throughout the coxmtry practicing different standards of care 
and documentation. As is the case in other segments of the healthcare industry, even 
seemingly simple tasks of commimicating among the various entities, as well as among 
sections of a single providing entity, is severely hampered by the lack of a common 
communication format. This is especially evident when certain aspects of the system 
(such as computerized clinical laboratory result displays) have been upgraded with a 
uniquely tailored computerized system, while the remaining fimctions are still 
performed in an archaic manner. While the upgraded system may be effective for one 
singular aspect, such as dispatching, lab reporting, or chart dictating, the remainder of 
the system does not improve its effectiveness due to the other archaic components. 

Current federal reimbursement changes for medical transportation are 
directed to acknowledge rural transports as being more expensive to accomplish 
because of the distances involved and the lower volume of transports. Current methods 
of attaching these modifiers are labor intensive and error prone. In many cases they are 
just not done because of the difficulty in applying them. There are significant financial 
benefits to adding these modifiers correctly and there are significant compliance risks to 
adding them incorrectly. What is desired is a capability to consistently apply transport 
associated modifiers in a compliant fashion. Furthermore, a capability where billing 
modifiers are applied to transport information would enhance a medical database 



system and is therefore also needed. Such biUing modifiers would allow rural providers 
a financial advantage to offset low volumes of work, for ex^ple. 

Summary of Certain Inventive Aspects 

One aspect of the present invention is an integrated emergency medical 
transportation database system having a billing modifier module, the system comprising 
a medical emergency database configured to store at least clinical encounter 
information, patient demographic data and transport information; and a billing modifier 
module, wherein the billing modifier module accesses a clinical encounter location 
stored in the medical emergency database and compares the chnical encounter location 
to a list of geographic areas, and wherein the result of the comparison is used to apply 
billing modifiers to the medical ch^ges associated with the medical emergency. 

Another aspect of the invention is a method of billing modification for an 
integrated emergency medical transportation database system, the method comprising 
collecting at least chnical encounter information, patient demographic data and 
transport information into a medical emergency database; accessing a clinical encounter 
location stored in the medical emergency database; and comparing the chnical 
encounter location to a list of geographic areas, wherein the result of the comparison is 
used to apply a billing modifier to the medical charges associated with the medical 
emergency. 

Brief Description of the Drawings 

Figure 1 is a diagram illustrating the on-line computing environment of one 
embodiment of the medical database system, including a dispatch interface computer, 
server computer, backup computer, clinical and diagnosis interface computer, 
administrative interface computer and billing interface computer. 

Figure 2 is a block diagram illustrating one embodiment of the flow of data 
among a Dispatch module, a Chnical module, and a Billing module, m one embodiment 
of the medical database system. 

Figure 3 is a flow diagram illustrating one embodiment of the Billing Modifier 
module process shown in Figure 2. 



Detailed Description of Certain Inventive Embodiments 
The following detailed description presents a description of certain specific 

embodiments of the present invention. In this description, reference is made to the 

drawings wherein like parts are designated with like numerals throughout. 

For convenience, the discussion of the invention is organized into the following 

principal sections: Introduction, Hardware Overview, Data Flow Between Modules, 

Description of Software Module, and Conclusion. 

INTRODUCTION 

In certain embodiments, the present invention relates to an object oriented, 
interactive, international, chent-server service for the medical transport industry. The 
service may integrate all aspects of patient record documentation into a single complete 
electronic chart. A server computer provides chart database information access to 
multiple transport providers simultaneously by securely transmitting, storing and 
maintaining standardized patient data, for instance, using guidelines set forth by the 
Scrambling Standards Organization. Individual transport-providing entities, such as 
hehcopter and ambulance companies, obtain coded access to this server via phone lines 
with a modem equipped personal computer. Security is maintained by assigning each 
entity a imique code or identifier. Integrated Services Digital Network (ISDN) lines, 
Digital Satellite Systems (DSS), dedicated trunk lines (Tl, T3, etc.), cable modem, 
DSL, or digital wireless systems may also be used for communication. 

Each crew member involved in the patient's chart documentation, i.e., 
dispatcher, flight nurse, paramedic and physician, as well as administrator and collector, 
possess coded access to chart portions relevant to their responsibilities and level of care 
provided. The chart is then electronically generated fi-om the compendium of the 
information entered in a standardized fashion and in accordance with minimum industry 
documentation requirements and the inventory of financial health care standards. The 
system provides complete and accurate chart documentation and maintains internal 
consistency between each separate module. Furthermore, any sentinel events are 
automatically referred to the appropriate, responsible party. A sentinel event is any 
action during the encounter that might require a further review. Examples of sentinel 
events are scene times exceeding 40 minutes, nonsensical or inconsistent data entry by 



an emergency transport crew member, supply shortages for equipment not utilized or 
repeated claim denials. 

Billing can be submitted electronically to the appropriate party in an appropriate 
format that reduces the accounts receivable times for each patient encoxmter. Letters of 
justification are automatically generated as well as follow up letters and utilization 
review reports. Inventory reports and lists of necessary base supplies and medicines are 
also electronically updated to appropriate supply centers and administrators. 
Customized and research reports can also be provided rapidly. 

Data security and an automatic backup are provided. Although the chart data is 
normally made the property of the respective transport service provider, the system can 
retain non-proprietary data to provide industry benchmarking, quality assurance 
analysis and clinical research opportunities. Such standardized data collection and 
documentation will furthermore enable the development of an Emergency Medical 
Services data library to assist in the justification and legislation of governmental 
preventive policies for public safety. 

HARDWARE OVERVIEW 
Figure 1 provides an overview of the computer hardware involved in one 
embodiment of the medical database system. In this embodiment, the medical database 
system 10 includes a server computer 12. The server computer 12 can be based on any 
well-known microprocessor such as those manufactured by Intel, Motorola, IBM or 
others. The server computer should be able to enable rapid simultaneous access to 
many users of the system. In one embodiment, the server computer 12 is an Intel 
Pentium III class computer having at least 256 Megabytes of RAM and a 10 gigabyte 
hard disk drive and a 500 MHz processing speed. Of course, many other standard or 
non-standard computers may support various embodiments of the medical database 
system 10. 

The database appUcation may be programmed in, for instance, ACIUS's 4th 
Dimension (4D) language and used in conjunction with the 4D Server and Ghent 
program. Also, another alternative computer environment is Microsoft Corporation's 
Visual Basic language with C++ middleware, and the BackOffice SQL Server program. 
It can therefore run in a standard Windows/Macintosh point-and-chck office 



environment, and requires no additional, specialized software programming from the 
user. Of course, other standard or non-standard computer environments may support 
various embodiments of the medical database system 10. 

As illustrated, the server computer can access a chart database 13. The chart 
database 13 stores the previously described electronic charts corresponding to patients 
that have utiUzed emergency medical transportation. The server computer can also 
access a statistical database 14 to store and extract statistical information from data 
entered during patient encounters. The collected statistics might include, for example, 
average scene and transport times, number of transport requests per demographic region 
and time of year, average number of advanced procedures performed by crew members 
and number of compUcations encountered. In addition, the database 14 can hold 
information relating to the average length of time to process claims by category and 
payment plan. 

The server computer can also be linked to a regional trauma database 15. The 
database 15 holds information relating to local trauma centers, emergency medical 
practice and other local trauma-related information. 

The dispatch module on the server computer 12 can be accessed via an interface 
to a dispatch computer 20, which might reside, for example, at the dispatch center that 
receives the initial call to deploy an emergency medical team. The dispatch computer 
20 can provide just a communications interface to the server computer 12 so that it acts 
as computer terminal, or it can contain a portion of the dispatch module. 

Based on the scene location and needs of the patient, the dispatch center might 
deploy a heUcopter 24, airplane 25, ambulance 26, or other transportation mechanism. 
The dispatch computer 20 communicates with software for collecting information on 
the patient encounter and scheduling and deploying a crew to assist the injured patient. 
Within the medical database system 10, the helicopter 24, airplane 25 or ambulance 26 
would include a portable computer or computing device 30 (note that the portable 
computer 30 may be any electronic device that includes computing capability) that is 
used by the emergency medical team during the patient encounter. A wireless 
connection 32 can be made by the portable computer 30 to the server computer 12 to 
update the database 14 after any data has been entered. In other embodiments, other 
ways of communication with the server 12 can be used. The portable computer 30 can 



include clinical and diagnosis modules to assist the emergency medical team in treating 
the injured patient, or can act as a terminal to communicate with these modules on the 
server computer 12. As will be explained below, the clinical and diagnosis modules can 
help the emergency medical team determine the proper diagnosis and treatment of the 
patient. 

The medical database system 10 also includes a billing computer 36 in 
communication with the server computer 12. The billing computer 36 interfaces with 
the server computer 12 to run the billing module for tracking charges. The software 
billing module can be stored directly on the billing computer 36 or, ahematively, stored 
on the server 12 and accessed via the billing computer 36. The billing module is used to 
track charges, inventory, and medical equipment. In addition, it is used during the 
patient encounter for providing billing functions within the medical database system 10. 
The billing computer 36 communicates with a laser printer 38 to provide printed reports 
and bills to hospitals, patients and medical centers. 

An administration computer 40 interfaces with the server computer 12 to 
provide run administrative reports. These reports might relate to the statistical 
information contained in the statistical database 14. In addition, the administration 
computer 40 might ran reports that relate to payroll, inventory, flight training or many 
other administrative issues. 

It should be noted that the dispatch interface computer 20, portable computer 30, 
billing computer 36 and administration computer 40 can communicate with the server 
computer 12 through a variety of mechanisms, as shown by connection paths 32 and 33. 
For example, a wireless LAN or cellular network may connect each computer with one 
another. In another embodiment, dedicated or dial-up phone lines can be used to 
communicate between the different computers. Communication mechanisms may 
include networks such as the Intemet and may include virtual private networks (VPNs), 
which are further discussed in Applicant's copending Patent Application No. 

, entitled INTEGRATED EMERGENCY MEDICAL 

TRANSPORTATION DATABASE AND VIRTUAL PRIVATE NETWORK 
SYSTEM, and which is hereby incorporated by reference. 



DATA FLOW BETWEEN MODULES 

Referring now to Figure 2, a block diagram of one embodiment of the data flow 
between the various modules within the medical database system is illustrated. Figure 2 
illustrates the flow of data between a dispatch and demographic module 100 (hereafter 
referred to as the dispatch module), a clinical module 105 and a billing module 110. 
The dispatch module 100 includes a scheduling submodule 112, a standby submodule 
1 14, a transfer submodule 1 16 and a flight submodule 1 18. These various submodules 
process information received into the overall dispatch module 100. For example, crew 
information 120 is processed within the schedule submodule 112. In addition, scene 
information 122 is processed within the standby submodule 114. 

Patient demographics and patient lab information 124 is processed within the 
transfer submodule 116. Fhght tracking and other transportation information 126 is 
processed within the flight submodule 118. Once the various submodules within the 
dispatch module 100 have processed their respective information, a set of patient 
demographic information 130 and flight/transport information 135 is made available to 
the remaining modules. For example, some of the patient demographic information 130 
is imported into the clinical module 105. 

In addition, many other pieces of data are placed within the clinical module 105. 
For example, the general assessment 140 of the patient that is taken by the emergency 
medical team is imported into the clinical module for further processing. In addition, 
other incident information 142 such as the type of incident (car accident, motorcycle 
accident, etc.) is sent to the clinical module 105. Prior treatment information 144 
obtained from a physical exam of the patient or other information is also sent to the 
clinical module 105. 

The prior treatment information might be important in determining whether the 
patient had already been treated for similar injuries thereby affecting the clinical 
diagnosis. Information collected from the physical exam 146 at the scene is also sent to 
the clinical module 105. In addition, any diagnosis 148 from the attending emergency 
medical team can be sent to the clinical module 105. It should be noted, as discussed 
below, that the medical database system 10 may also provide a diagnosis based on the 
physical exam information 146 and other information within the clinical module 105. 
This will be explained in more detail below. 



Information relating to the treatment 150 of the patient is also sent to the clinical 
module 105, The medical database system 10 also includes a quality assurance 
database 152 which allows the emergency medical team to make suggestions or other 
comments that may be useful in additional treatments or incidents. For example, if the 
emergency medical team notes that a particular series of exam results has led to a 
unique diagnosis, this information can be input into the clinical module 105. Thus, the 
next time these same physical exam results are seen in a patient, the new diagnosis can 
be suggested to the emergency medical team. 

Once the clinical module 105 has received its necessary information, data is 
output to the billing module 110. For example, a description of the diagnosis 160, a 
treatment description 162 or ICD-9 codes 165 can be sent from the clinical module 105 
to the billing module 110. As is well known, ICD-9 codes are a set of unique codes 
referring to most well known medical procedures. These codes are used throughout the 
insurance industry to obtain payment for various medical procedures. In addition to the 
data from the clinical module 105, patient data 168 can be obtained from the patient 
demographic information 130. The flight/transport information 135 can be processed 
by a billing modifiers module 166. The processed data from the billing modifiers 
module 166 can be fed into the billing module 110. The billing modifiers module 166 
will be described in conjunction with Figure 3 below. The information received at the 
billing module 110 is then used within the billing module to generate reports and bills 
170. As is to be expected, these reports and bills are sent to the various insurance 
companies and insurance providers. Thus, the medical database system 10 is an 
integrated system for providing many services within the medical industry. Further 
descriptions of the software modules are provided in AppUcant's U.S. Patent No. 
6,1 17,073, which is hereby incorporated by reference. 

DESCRIPTION OF SOFTWARE MODULE 
The Billing Modifiers Module 

Referring now to Figure 3, a flow diagram illustrating one embodiment of the 
biUing modifiers module process 166 (Figure 2) is described. In one embodiment, prior 
to assembling data for production of a charge document, such as a bill, the billing 
modifiers module process 166 analyzes the patient pickup data including ZIP code, 



Global Positioning Satellite (GPS) coordinates, and latitude/longitude. The module 166 
then appUes Geographic Practice Cost Index (GPCI) and Metropolitan Statistical Area 
(MSA) billing modifiers appropriately— including the use of the Goldsmith correction 
factor of the MSA— and then adjusts the bill according to modifiable, computerized 
rules based on these modifiers. This provides for a more accurate charge to the payer. 
In one embodiment, the MSA and the GPCI are determined by the federal government 
and are distributed in non-proprietary datafiles. 

As described above, specific transport information is collected at the dispatch 
and demographic module 100, such as by the transport (flight) submodule 118. In one 
embodiment, the collected transport data is screened for patient pick-up ZIP code and 
GPS data to generate the transport information 135. The transport information 135 can 
be forwarded to the billing modifiers module process 166. 

In one embodiment, there are two billing modifiers: GPCI and MSA. These 
modifiers are multiplicative and increase the bill when they are applied. These 
modifiers are designed to allow rural providers a financial advantage to offset low 
volumes of work. The MSA is a yes/no answer (a MSA status of no means rural) and 
the GPCI is a number, such as, for example 0.933, Once the flight information 135 has 
been generated fi-om the dispatch module 100, a determination is made at a decision 
state 1102 whether the ZIP code and global positioning sateUite coordinates of the 
patient pick-up point are within a GPCI and/or a MSA. 

This determination is made by linking the flight information 135 to a 
GPCI/MSA library 1110 that stores the ZIP codes, GPS coordinates and/or 
latitude/longitude of the GPCI and MSA areas along with the appropriate factor to be 
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used to adjust bills within the designated area. Table 1 illustrates an exemplary portion 
of one embodiment of the library 1110. 



TABLE! 



COUNTY 
NAME 


State 


GPCI 


MSA 


ZIP 
CODE 


GPS 


AUTAUGA 


AL 


0.872 


YES 


12910 


Lat/Lon 


BALDWIN 


AL 


0.872 


YES 


12911 


Lat/Lon 


BARBOUR 


AL 


0.872 


NO 


12912 


Lat/Lon 


BIBB 


AL 


0.872 


NO 


12913 


Lat/Lon 


BLOUNT 


AL 


0.872 


YES 


12914 


Lat/Lon 


BULLOCK 


AL 


0.872 


NO 


12915 


Lat/Lon 


BUTLER 


AL 


0.872 


NO 


12911 


Lat/Lon 


CALHOUN 


AL 


0.872 


YES 


12911 


Lat/Lon 



If a determination is made that the Zff code is not within a GPCI or MSA area, the 
flight data 135 is forwarded directly to the billing module 1 10 without adjustment. 

More specifically, at state 1102, the ZIP code and GPS coordinate data 
(converted to ZIP code in one embodiment) are evaluated and compared to the 
GPCI/MSA library 1110 so as to allow a modifier to be attached to the claim 
consistently. The GPCI is applied to every claim for the bill at this point as each ZIP 
code has a specific index. Note that all claims have an associated GPCI based on ZIP 
code. Pick-ups within an MSA are not eligible for this modifier unless they are 
acknowledged as appropriate for the Goldsmith correction. The Goldsmith correction is 
used in ZIP codes that are largely rural but have more than 50,000 people (definition of 
an MSA) in the ZIP code in one small area of the ZIP code. For example, a big city 
located in one comer of a ZIP code with a huge rural area would be eligible for 
Goldsmith correction. 

However, if the ZIP code and/or GPS coordinates of the flight information are 
within a GPCI and/or MSA area, the correct fee modifiers are appUed by state 1112 to 
recalculate the appropriate transport charges before forwarding them to the billing 
module 1 10. More particularly, if the pickup ZIP code and/or GPS coordinate indicates 
that the location is NOT in a MSA, then the modifier is appUed. Once the MSA status 
(if applicable) and GPCI have been appUed, the charges are recalculated with these 
modifiers. 
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As an example, a ZIP code 92075 is compared to the library 1110, 

COUNTY ZIP 

NAME State GPCI MSA CODE GPS 

San Diego CA 1.045 YES 92075 Lat/Lon 



the zip code hbrary indicates the county as San Diego, yes it is an MSA, so no MSA 
modifier is appUcable, GPCI is 1.045. The modifier for GPCI is appUed and charges 
are calculated. In one embodiment, portions of the GPCI/MSA library 1 1 10 are derived 
from a ZIP code file which contains all ZIP codes in the United States and identifies 
which are rural (non-MSA). This file includes those areas that fall into the Goldsmith 
modification. The ZIP codes determined as rural under the Goldsmith modification are 
listed as rural in the file. The ZIP code file may be downloaded from the former Health 
Care Financing Administration (HCFA) (now called the Center for Medicaid and 
Medicare (CMS)) mainframe ( address is MU00.@AAA239Q.ZIP.LOCALITY ) into a 
modifiable library data file. 

In one embodiment, an example of the processing at state 1 1 12 follows: 

GPCI 

GPCI( X % of the base rate) + the Base rate = the Modified Base rate 
MSA 

the first X miles will be subject to a higher payment per mile when transport is from a 
non-MSA + the standard payment for loaded mileage for the X-total miles 

X miles( base charge per mile + Y dollars per mile) + Total miles- X( base charge per 
mile) 

where: 

X= the first number of loaded mileage allowed for modification 
Y= the incremental increase in charge for the modified miles 

Thus, prior to assembling data for entry into the billing module 1 10, the process 
166 analyzes the patient pick up data, including ZIP code and GPS coordinates, to apply 
the proper MSA and GPCI billing modifiers. These modifiers preferably include the 
Goldsmith correction factor of the MSA. The billing modifiers module process 166 
thus correctly adjusts the bill to properly charge for pick-ups within these particular 
areas. 
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At the completion of state 1112, or if the MSA modifiers do not need to be 
applied, as determined at decision state 1102, process 166 completes and then the 
record is released for billing review and bill preparation at the billing module 110. That 
is, if the data is not sufficient enough to apply modifiers, or has already recalculated 
with modifiers, the charges are forwarded to the billing module 110 and are placed 
directly on electronic or paper forms. The charges with modifiers and those not eUgible 
for MSA status are tracked such that impact of the application of modifiers is reportable 
to demonstrate fiscal advantage of the modifiers at 170. 

CONCLUSION 

Specific blocks, sections, devices, functions and modules may have been set forth. 
However, a skilled technologist will reahze that there are many ways to partition the 
system of the present invention, and that there are many parts, components, modules or 
fimctions that may be substituted for those listed above. 

As should be appreciated by a skilled technologist, the processes that are 
undergone by the above described software may be arbitrarily redistributed to other 
modules, or combined together in a single module, or made available in a shareable 
dynamic Unk library. The software may be written in any programming language such 
as C, C++, BASIC or Visual BASIC, Pascal, Java, and FORTRAN and executed under 
a well-known operating system, such as variants of Windows, Macintosh, Unix, Linux, 
VxWorks, or other operating system. C, C++, BASIC or Visual BASIC, Pascal, Java, 
and FORTRAN are industry standard programming languages for which many 
commercial compilers can be used to create executable code. A database programming 
language such as ACIUS's 4th Dimension (4D) language used in conjunction with the 
4D Server and Client program may also be used. 

While the invention has been described in connection with specific embodiments 
thereof, it will be understood that it is capable of fiirther modification, and this application 
is intended to cover any variations, uses, or adaptations of the invention following, in 
general, the principles of the invention and including such departures firom the present 
invention as would be understood to those in the art as equivalent and the scope and 
context of the present invention is to be interpreted as including such equivalents and 
construed in accordance with the claims appended hereto. 
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